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CONFERENCING SYSTEM 
Field of the Invention 

The present invention relates to a method and apparatus for setting up conference calls 
in communication systems, and in particular but not exclusively to wireless 
communication systems. 

Background of the Invention 

The concept of conference calls in public switched telephone networks (PSTN) is well 
known. PSTN conferences are typically set up by a first participant calling a specific 
customer support number and being supplied with a conference bridge number and a 
PIN code. The first participant can then provide this information to any other potential 
participants. The participants wishing to join the call would each dial the conference 
bridge number, and supply the PIN code on demand, and would subsequently be 
admitted to the conference call. 

As an alternative, the Internet could conceivably be used to arrange conference calls. 
A specific web site could be accessed by a first participant, and a bridge number and 
PIN code could be obtained. The first participant would then be able to provide the 
details to other participants. 

Roth of these procedures allow for a mobile terminal to be involved in the conference 
call. However, both procedures have two main disadvantages. Firstly, a conference 
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call must be planned in advance. The various participants must contact each other so 
that they each know when the call is due to take place and can dial the conference 
bridge number at that time. Secondly, the participants themselves need to organise for 
the bridge number and the PIN code to be distributed to all participants. 

There have been various models proposed for providing conferencing services in third 
generation Internet Protocol Multimedia Subsystem (IMS) wireless communication 
systems, for example in IETF draft "Models for Multi Party Conferencing in SIP", J. 
Rosenberg and H. Schulzrinne. Each of the models in this draft uses Session Initiation 
Protocol (SIP) messaging. The SIP protocol is discussed in Internet Standards RFC 
3261 and RFC 2543. Some of the models are described briefly below. 

The first model, known as "end system mixing", requires that one terminal involved 
in a conference call performs the mixing (merging) of signals and media streams sent 
to and from other terminals in the call. Figure la is a depiction of a three-way call 
using this model. In this example, users A and B are involved in a two-way call. At 
some point during the call, user A decides to bring user C into the call To do this, user 
A calls user C using a completely separate SIP call. There is no call set up between B 
and C. Instead, A receives media streams from both B and C and mixes them. 
Terminal A sends a stream containing the streams of A and B to terminal C, and a 
stream containing A's and Cs streams to terminal B. In this model, terminals B and C 
are unaware from a SIP perspective that the call involves more than two parties. 

In the case of a call involving more than three terminals, more than one terminal may 
perform mixing and signalling to sustain the call. For instance, as an extension of the 
above-described example, user C may decide to invite a fourth user D into the 
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conference call. User C would then call user D and terminal C would perform the 
mixing of the streams it receives from terminal A with its own stream, and send the 
combined stream to D, and mix its own stream with that of D and send this to A. This 
set-up is shown in Figure lb. 

Serious disadvantages of this model are that when a mixing terminal leaves the call, 
the conference must end, and thai there is no way for a mixing terminal to determine 
whether a signalling message sent to it was intended for that terminal alone or for all 
terminals in the conference. 

A further model, using dial-in conference servers, closely mirrors the PSTN system 
described above. One participant defines a URI (uniform resource identifier) to 
identify a conference call, and sends it to other participants. The participants then each 
call the server, using the conference URI, which maintains point-to-point SIP 
relationships with each participant that calls in. The server receives media from each 
participant, mixes them, and sends out the appropriate mixed stream to each 
participant separately. This model is depicted in Figure 2, which shows four users A-D 
taking part in a conference call. 

Dial-in conference servers are versatile in that they can be used for pre-arranged 
conferences or for ad hoc conferences. However, this model suffers from the fact that 
it is possible for the same URI to be used for more than one conference. This would 
cause conference sessions to be mixed. 

It is an object of the present invention to provide a solution to one or more of the 
above-stated problems. 
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Summary of the Invention 

According to a first aspect of the present invention there is provided a method for 
administering conferencing resources in a communications system comprising a 
plurality of terminals and a conference server, the method comprising: transmitting 
from a first terminal to the server a first message comprising a request for a resource 
capable of sustaining a conference call; allocating by means of the server a network 
address identifying a resource capable of sustaining the conference call; and 
transmitting from the server to the first terminal a second message comprising the 
network address. 

Advantageously, the method allows for conferences to be set up on an ad hoc basis so 
that the conferences need not be pre-arranged. In addition, the method prevents the 
problem of overlapping conference sessions. This problem is overcome by providing 
for a server to allocate a resource for a conference, and a corresponding address for 
that resource. In this way, an address can be unique to a particular conference at a 
given time. 

A further advantage of the present invention is that it allows for the use of standard 
SIP messages in the establishment of a conference call. Furthermore, no significant 
user configuration is required in the allocation of conferencing resources. 

Preferably a user transmits the network address from the first terminal to terminals of 
other users that will take part in the conference call. Preferably connections are 
initiated between the terminals and the network address to establish the conference 
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call. 

According to a second aspect of the present invention there is provided a conference 
server for administering conferencing resources in a communications system 
comprising a plurality of terminals, the conference server comprising: a receiver unit 
for receiving from a first terminal a first message comprising a request for a resource 
capable of sustaining a conference call; an allocation unit for allocating a network 
address identifying a resource capable of sustaining the conference call; and a 
transmission unit for transmitting to the first terminal a second message comprising 
the network address. 

Preferably the receiving unit is arranged to receive from a first terminal a first 
message comprising a request for a resource capable of sustaining a conference call. 
Preferably the allocation unit is arranged to allocate a network address identifying a 
resource capable of sustaining the conference call. Preferably the transmission unit is 
arranged to transmit to the first terminal a second message comprising the network 
address. 

The server could be provided at a single location, or by functionality that is distributed 
between two or more locations. 

According to a third aspect of the present invention there is provided a 
communications system comprising: a conference server for administering 
conferencing resources in a communications system comprising a plurality of 
terminals, the conference server comprising: a receiver unit for receiving from a first 
terminal a first message comprising a request for a resource capable of sustaining a 
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conference call; an allocation unit for allocating a network address identifying a 
resource capable of sustaining the conference call; and a transmission unit for 
transmitting to the first terminal a second message comprising the network address; 
and a plurality of terminals including the first terminal. 

Brief Description of Drawings 

The present invention will now be described by way of example with reference to the 
accompanying drawings, in which: 

Figure 1 shows a prior art model for a conferencing system; 

Figure 2 shows a prior art dial-in conferencing system; 

Figure 3 shows a conferencing system according to the invention. 

Detailed Description of the Invention 

The invention is described hereinbelow with reference to a non-limiting embodiment. 
In particular, the invention is described in relation to SIP signalling in a 3G IMS 
mobile communications network. However, the invention is not limited to such 
signalling or such a network. 

Referring to Figure 3, two user agents 10 and 11 are shown. A first user, using user 
agent 10, wishes to start a conference call involving user agent 11 and sends a SIP 
INVITE message 21 to a well-known URI at an operator to initiate the conferencing 
process. That URI could be stored by the user agent 10, The INVITE message 21 
indicates that user agent 10 wishes to initiate a conference, and the Request-URI 
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could suitably take the form: 
sip : conf erences@sonera . f i 

The INVITE message could include details of the type of conference required, for 
example a preferred data rate. These details could be contained in the media 
components listed in the Session Description Protocol (SDP) payload of the INVITE 
21. 

The message 21 is received at a conference server 12 which is preferably a generic 
user agent server. At this stage, the server 12 could authenticate the conference request 
by transmitting a SIP message containing an authentication challenge to the user agent 
10 requesting details such as a username and a password. In this case, the user would 
then need to provide such details, i.e. valid authentication credentials, in order for the 
conference request to be authorised. 

Either in response to receiving message 21, or in response to receiving valid 
authentication information from user agent 10, the server 12 allocates a dynamic SIP 
UR1 to be used for the requested conference. The dynamic URI identifies a resource 
13 that is available to be used for supporting the requested conference according to 
the specifications listed by the first user in the INVITE 21. The network is arranged to 
route to the resource, or the unit that provides the resource, communications directed 
to that address. To facilitate this the server is preferably arranged to allocate 
addresses for conferencing according to a prc-sct pattern so that they will all refer to a 
suitable conferencing resource. The server 12 may reserve this resource so that it 
remains available until the requested conference begins. Alternatively, no resource 
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may be reserved by the server 12 but instead an available resource could be located at 
the time when the requested conference is initiated. The resource is capable of 
establishing point-to-point connections with a terminal of each participant in a 
conference call. It can merge the traffic signals it receives from each terminal and 
transmit the merged signals to the other terminals that are parties to the conference 
call. Those traffic signals could carry voice data or other data such as video or 
graphical (e.g. whiteboarding) data. The resource could be data handling capacity, 
bandwidth or any other resource necessary for sustaining a conference call. The 
resource could be provided by physical equipment such as a part of a server. 

The dynamic URI is transmitted to user agent 10 by conference server 12 in a SIP 
message 22. The message 22 is preferably a redirection message with a code in the 
3xx range, and the URI is preferably contained in the contact field of the message. An 
examples of the form that the contact field could suitably takeis: 

Contact : <sip:DKLSKX87KKJ98 9SKFKJH@conference .soaera . £i> 

On receipt of the redirection message including the allocated URI, the user agent 10 
then transmits an INVITE message 23 to the URI. The URI identifies the reserved 
conference resource 13, and responsive to receiving the INVITE message 23, the 
resource 1 3 sends an acknowledgement, such as a 200 OK message 24. back to user 
agent 10. 

Once user agent 10 receives the 200 OK message, the first user can then refer the 
allocated URI to a second user at user agent 11. A further message, such as a SIP 
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REFER message 25, including the UR1 is transmitted from user agent 10 to user agent 
1 1 . The REFER could suitably take the form: 

REFER sip: user_b@pp.radiolinja.fi SIP/2.0 

with the following header: 

Refer-To : sip : DKLSKX87KKJ989SHFKJH@conf erence . sonera . f i ; 
Method- INVITE 

Alternatively, the URI could be sent from the First user to the second user in another 
way. 

By the above mechanism, a user can reserve a conference resource on the fly. Without 
any significant input on the part of the user, other participants can be connected 
together to form a conference call. 

In response tu receiving ihc REFER message from user agent 10, user agent 11 
transmits an acknowledgement, such as a 202 accepted message 26, back to user agent 
10. 

User agent 11 now transmits a request message, such as an INVITE message 27, to 
the reserved resource 13, in response to which the resource 13 sends an 
acknowledgement, such as a 200 OK message 28, to user agent 11. The server 12 and 
resource 13 are able to communicate with each other. In this way, the server can 
acquire authentication information obtained by the resource from a user so that each 
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user can be authenticated before being allowed to join the conference. For example, it 
may be desirable to check that a user has a subscription enabling him to take part in 
conferences. Details of subscriptions could be contained in authentication 
information. Alternatively, or additionally, a user may be required to input a PIN for 
transmission to the resource 13 to confirm his identity for security reasons. 

Following message 28, an acknowledgement, such as a NOTIFY message 29 with 
response code 200 OK, is sent from user agent 1 1 to user agent 10, and the conference 
may begin. 

It will be apparent that user agent 10 can also send or REFER the dynamic UR1 to a 
number of other users so that they can take part in the conference. A further 
alternative is that the REFER message 25 could be directed to the conference URL In 
other words, instead of referring user B to the conference, the conference could be 
referred to user B. The same set of messages could be used as described above, but in 
this case they are used with dial-out semantics. 

A summary of the messages required to set up a conference according to a preferred 
embodiment of the invention is given below. 

2 1 INVITE to sipxon ferences@sonera.fi 

22 3xx redirection including dynamic URI 

23 INVITE to URI 

24 200 OK 

25 REFER to UA 11 

26 202 accepted 
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27 INVITE to URI 

28 200 OK 

29 NOTIFY with response code 200 OK 

The mechanism described above can also facilitate dial-in conferences. In the dial-in 
case, the mechanism would function in essentially the same manner as described 
above except that the conference URI would be delivered to prospective participants 
in a different way, for example via an Instant Message or email, rather than using a 
REFER message to invite them. 

The applicant draws attention to the fact that the present invention may include any 
feature or combination of features disclosed herein either implicitly or explicitly or 
any generalisation thereof, without limitation to the scope of any definitions set out 
above. In view of the foregoing description it will be evident to a person skilled in the 
art that various modifications may be made within the scope of the invention. 


